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Abstract 

In order to support global competitiveness and rapid 
market responsiveness, virtual enterprises need to effi- 
ciently integrate different organization 's workflows to pro- 
vide customized services. Currently, most of the integra- 
tions are case-based which have high setup cost and involve 
time consuming low level programming. Cross-enterprise 
workflow that is able to streamline and coordinate busi- 
ness processes across organizations in dynamic Web envi- 
ronment provides a low cost and flexible solution. We de- 
velop an agent-based cross-enterprise workflow Manage- 
ment System (WFMS) architecture which can dynamically 
integrate the workflows and compose a worlflow execution 
community customized to different workflow specifications. 



1. Introduction 

The support of cross-enterprise relationships is a key 
requirement for Business-to-Business (B2B) E-commerce. 
B2B E-commerce is a prime candidate to take advantage 
of the information revolution the WWW has brought about. 
Cheap connectivity and ease of advertising of business ser- 
vices (i.e., processes) on the Web created tremendous op- 
portunities for organizations of any size to diversify their 
customer-based and become truly global. The electronic 
availability of business processes (e.g., order procurement, 
customer relationship management, finance, accounting, 
human resources, supply chain and manufacturing) has built 
very high expectations for organizations to increase cus- 
tomer value and establish deeper relationships with part- 
ners. There are signs of this phenomenon even today. For 
example, GM (General Motors) announced in early 2000 
that it will move its main operations (i.e, design, manufac- 
turing, selling, and shipping of cars) to the Web [GenOO]. 



The ability to efficiently and effectively share business 
processes across the Web is a critical step in the develop- 
, ment of the new on-line economy. Organizations must be 
able to integrate their business processes across boundaries 
to form what is known as Virtual Enterprise [Geo99]. For 
example, in a supply chain manufacturing environment, the 
order placement process, order fulfillment process and ship- 
ment process might all be undertaken by different compa- 
nies. It is important for the customer who places an order 
to have the visibility of the whole process (from ordering 
to shipping). Dynamic integration of cross-enterprise busi- 
ness processes is an essential requirement for organizations 
to adapt their business practices to the highly volatile and 
dynamic nature of the Web. 

With respect to meeting the requirements of virtual en- 
terprises, we identified two relevant emerging technologies: 
workflows and agent technologies. As businesses move 
more and more of their activities on-line, workflow tech- 
nology is increasingly gaining relevance as a critical tech- 
nology for business process reengineering. Workflow Man- 
agement Systems (WFMSs) have achieved considerable im- 
provements in critical, contemporary measures of perfor- 
mance, such as cost, quality, service, and speed by coordi- 
nating and streamlining complex business processes within 
large organizations (e.g., health-care, education, banking 
and finance, stock-brokerage, manufacturing, communica- 
tion, and office automation applications). Current workflow 
systems are based on the premise that enterprise success re- 
quires the management of business processes in their en- 
tirety. Indeed, an increasing number of organizations have 
already automated their internal process management us- 
ing workflows and enjoyed substantial benefits in doing so. 
However, one of the most significant weaknesses of exist- 
ing WFMSs, is the lack of flexible mechanisms to cope ad- 
equately with cross-enterprises relationships. 

Despite the success of using workflow technology in au- 
tomating internal business processes, there has been little 
success to achieve dynamic integration of cross-enterprise 



workflows. Indeed, the development of integrated work- 
flows is still ad-hoc, time-consuming and requires enor- 
mous effort of low-level programming. This problem is ag- 
gravated by the added degree of dynamism, unpredictabil- 
ity, and distribution of the Web. The support of flexible and 
efficient integration of workflows requires the ability to effi- 
ciently discover and exploit business services in a dynamic 
and constantly growing environment. It also requires the 
capacity to dynamically establish relationships among busi- 
ness processes. 

Agents have emerged recently as an important paradigm 
for organizing many classes of distributed applications 
[HS97]. Agents are sophisticated software entities with 
a high degree of autonomy. They are charged to achieve 
certain tasks in collaboration with their peers. Agents 
may be incorporated into an existing application in or- 
der to add new functions or customize the execution of 
existing functions according to specific requirements, op- 
erating conditions or observations of user behavior. An 
agent-based framework will provide component autonomy, 
multi-party negotiation and pro-activeness. These prop- 
erties make agent technology one of the most important 
candidates for providing interoperability and interactions in 
volatile, dynamic and cooperative environments. However, 
successful multi-agents system like InfoSleuth[NBN99], 
Warren/Restina[SKWL99] do not have the concept of a 
business process model. This means asking a multi-agent 
system to process workflow requires writing a complete 
new workflow engine each time which is a daunting task. 

In this paper, we propose an approach that com- 
bines agents with workflows to effectively integrate cross- 
enterprise workflows. The problem with current workflow 
technology is the inability to cope with dynamic interac- 
tions and interoperability which is what an agent can pro- 
vide. A cross-enterprise workflow instance can be regarded 
as a collection of tasks combined in certain ways by a pro- 
cess/control agent. The tasks can be assigned to different 
service providers and executed in a distributed environment. 
In our approach, among other things, agents are used to 
encapsulate (i.e., wrap) services which are able to execute 
workflow tasks. Based on the requirements of tasks, our 
system searches for agents with matching capabilities. The 
relevant agents are used to execute the tasks which are dy- 
namically composed by the system in order to provide the 
whole service. Agents are not only used to encapsulate ser- 
vices, but also advertise, search and coordinate them. In 
section 2, we present the model that we use to describe 
workflow processes. In section 3.1, we present an agent- 
based workflow architecture. In section 4, we present the 
execution of a cross-enterprise workflow in the proposed 
architecture. We discuss related work and summarize our 
findings in section 5. 



2 Workflow Specification Model 

We propose a component-based workflow model. Us- 
ing this model, major parts of a workflow process can be 
represented as component processes (i.e., tasks or work- 
flows). Thus, a higher-level specification that provides a 
cross-enterprise workflow process can be composed from 
existing component workflows.- Workflow components can 
be reused and specialized in different organization settings. 
A workflow process is represented as a tuple W: 
W = {T,E^,IUv) where: 

1. T is a set of tasks: T = {U, 1^2,. ..in] 

2. is a set of workflow Event-Condition-Action(ECA) 
rules: E-w = {ei, 62, •••^n}- The workflow ECA rule 
specifies the coordination among the tasks. In order to 
define the ECA rules, we use the following operations: 

• At: Enables the execution of the task t\ 

• Vt: Disables the execution of the task *; 

• ^ t\ Sends a message to the task t\ 

• icW: Starts the execution of the workflow W\ 

• OW'. Finishes the execution of the workflow W. 

A workflow ECA's rule is defined as follows: 

{ti.result == R) =^ A<j, 

which means enable the execution of task when the 
execution the task U returns R. 

3. Hw is the result of the workflow execution. It can be 
success, failure or null. It is initialized to 
null before a workflow begins. 

A task is represented as a tuple U : 
U = {NuPuOuEiuDuRti) where: 

1 . Ni 'xs the name of the task, which is a mandatory string 
to identify the task. 

2. Pi'xs type of the task, which can be required or op- 
tional. All the required tasks must be executed 
and completed successfully. A workflow can still pro- 
ceed even if an optional task was failed or not been 
executed. 

,3. Oi is the task object, which is a tuple (P, S,TR, OP) 
where: 

(a) P is a set of properties that represent general in- 
formation about the task object (e.g., the creator 
of the task). 

(b) 5 is a set of possible states: S — {si, 52, .-Sn}. 
where: 



i. Si is the initial state: 5t € 5 

ii. Se is the final state: Se € 5, if object's state 
changes to 5e> it implies that the execution 
of the task is successful. 

iii. 5/ is the failure state: Sf € 5, if object's 
state changes to s/, it implies that the task 
fails to be executed. 

(c) TR is set of possible transitions (5<,Sj), where 

(d) OP is the set of operations on S, such that TR C 
5 X OP X 5 

4. Eii is asetofECA rules: En = {en,et2j •■•€in}- The 
ECA rules are used to define how the task coordinates 
or synchronizes with other tasks. Two kinds of rules 
are supplied: 

• C — > A : if condition C is true, then operation 
A might be executed. 

• C =^ A : if condition C is true, then operation 
A must be executed. 

5. Di IS the deadline of the task. 

6. Rti is the result of the task execution (i.e, success , 
failure, or null) which is set initially to null. 

In this model, we distinguish workflow ECA rules from 
task ECA rules. Workflow ECA rules are used to specify 
the interaction among workflow tasks, for example when to 
synchronize, when to make a choice. Task ECA rules are 
used to guide the execution procedure of individual tasks, 
for example when to trigger related operations. It should be 
noted that a task can be atomic or complex (i.e., a work- 
flow). In our model, the definition of a cross-enterprise 
workflow involves the identification of the tasks that com- 
pose the workflow and specification of the interactions be- 
tween them. This is different fi^om traditional workflow 
where it is also necessary to define who will be responsible 
for the execution of each task and how much time is allo- 
cated for each task at specification time. In our approach, 
tasks are dynamically assigned to service providers (i.e, en- 
tities that can perform the tasks, e.g., programs) during the 
enactment of a cross-enterprise workflow. The dynamic 
composition of tasks to provide a cross-enterprise workflow 
will be discussed further in section 4. 

3 Agent-based Workflow Architecture 

3.1 The Architecture 

The architecture we propose to support cross-enterprise 
workflows is shown in Figure 1. There are three logical 



components in this architecture: workflow definition tool, 
agent society and actual service. Workflow DefinUion Tool 
is responsible for defining cross-enterprise workflow spec- 
ifications. It allows a user to chart a personalized cross- 
enterprise workflow using a Web Browser based on existing 
templates. If none of the existing template is suitable, a new 
template need to be defined by a power user. Once the work- 
flow specification is verified to be syntactically correct, it is 
translated into the format as specified in Section 2. 

The Agent Society is a collection of agents that pro- 
vide the general functionalities of a cross-enterprise work- 
flow execution engine. There are three types of agents in 
the agent society, namely process agent, discovery agent 
and monitor agent. Actual Services ofTer applications (ser- 
vices) that allow users to access and perform tasks (e.g., 
order procurement, customer relationship management, fi- 
nance, accounting, human resources, supply chain and man- 
ufacturing). In our work, we are interested in services that 
are accessible through the Web. In order to abstract propri- 
etary services fi-om their physical organizations, we wrap 
them in service agents. The use of agents to execute cross- 
enterprise workflows is presented in the next section. Due 
to space constraints, the description of discovery agents is 
outside the scope of this paper. 




Figure 1. Agent-based WFMS Architecture 

3.2 Service Agent 

A service agent encapsulates a task that can be executed 
by a service provider. It contains the following informa- 
tion: (i) service identification, which indicates the port that 
the service agent listens to for requests, the format of the 
request message that it can understand and process(i.e its 
query processing capabilities), (ii) agent capabilities which 
specify the underlying service, and (iii) agent properties 
which specify service's constraints. For example, the flight 
ticket booking service can be represented in a service agent 
as shown in the figure 2. A service agent only accepts 
queries involving objects and operations that it advertised. 
It translates such a query into one or more requests that the 
actual service provider can understand. Upon receiving an- 




Agent identity 

agent name: Flight_agent 

agent address: 203.4.5.101:2323 

agent type: service 

agent interface: XML. SQL92 
Agent capabilities 

supported object: flight.ticket 

supported operations: reserve, unreserve, book, unbook 
supported query: price 
Agent properties 

agent constraint 1 : departure € {Sydney,Melboume} 

agent constraint 2: destination € {Hongkong, Beijing, NewYork} 



Figure 2. Service Agent 

swers for those local requests, it processes the answers if 
necessary, maps them to results in terms of what the re- 
questing agent can understand. 

3.3 Process Agent 

The process agent is in charge of transforming a work- 
flow specification into a workflow instance. As such, it has 
a number of duties and responsibilities: 

• The process agent assigns tasks to the relevant service 
agents. This is done by making a query to the dis- 
covery agent and finding the relevant available service 
agents. When a process agent receives many choices 
for performing a particular task, it lets the user who ini- 
tiated that particular task to make the final decision. It 
then makes connections to the service agent and sends 
task specifications to it. 

• Once a task is assigned to a service agent, a monitor 
agent is then created and sent to the task execution site. 
After the monitor agents migrate to the task execution 
sites, the process agent will instantiate the task ECA 
rules. 

• The process agent manages the execution flow of the 
tasks according to the workflow's ECA rules. It co- 
ordinates the tasks to achieve a certain goal. It can 
enable, disable, suspend or resume the tasks according 
to the workflow ECA rules. 

• During the execution of the workflow, process agent 
receives all the event messages from the monitor 
agents. This will enable user to be aware of the status 
of the workflow instance without having to subscribe 
to any service agent. 

• The process agent can forward the workflow specifica- 
tions to another process agent when it does not have 
the ability to process the specification. For example, a 



process agent specializes in design workflow will not 
be able to process a supply-chain workflow. 

3.4 Monitor Agent 

A monitor agent performs the actual monitoring of the 
execution of a given task at a local site. It has the following 
functionalities: 

• It migrates to the site where the corresponding task is 
executed. 

• It downloads the ECA rules of the corresponding task 
from the process agent. These ECA rules will guide 
the service agent in executing the task. 

• The monitor agent can be called back and updated by 
the process agent. And it also can re-migrate to con- 
tinue its monitoring function at the local site. 

• It informs the process agent and other monitor agents 
about the execution status of a task. This is done 
by sending messages to them when the service agent 
changes status of the task that it is responsible for exe- 
cution. 

4 Execution of Cross-Enterprise workflows 

During the life cycle of a workflow instance, the above 
four type of agents will form a community according to the 
specification of a particular workflow, work load of individ- 
ual agent and the quality of services those agents can pro- 
vide. The community disbands after the termination of the 
workflow execution. 

T « 

> ^ . Batf 

Figure 3. Business Trip Planing Worl^flow 



4.1 An Example 

Consider a business trip workflow application which is 
used by a salesman as shown in Figure 3. It involves inter- 
action among agents from an airline company, a hotel com- 
pany, and a car rental company. The business workflow has 
the following constraints: 

• The salesman can book the flight ticket and hotel at the 
same time. 



• If flight booking or hotel booking is not successful, the 
trip cannot proceed. 

• If both bookings are successful, there is an optional op- 
eration: Car Booking. The workflow can still proceed 
even if the car can not be rented 

Using the workflow model defined in section 2, this 
trip planning workflow, ff" can be declaratively.- defined as 
follows: 

Workflow W = {T,E^a,Rw], where: 

T= {ti,t2,t3} 

Etu = {cti,! , eto2}, where 
e^i : -kW ==>■ Ail A t2 

Ctt>2 : ((ti .result == success) A (t2 -result == success)) => Ats 
Ru, = null 

The tasks : 

ti = {Ni, Pi, Oi.EtuDiyRti], where 

Ni is flight ticket booking. Pi is required, Oi is Flight Ticket, defined as: 



States 
Operations 
reserve 
unreserve 
book 
unbook 



{request,reserved,unavailable,booked } 



(request,reserved) 
(reserved,request) 
(reserved,booked) 
(booked, request) 

Eii = {eii,ei2,ei3},where 

cii : {ti .Ticket.state == reserved) => ('>-» ^2)) 

€12 : (t^.Room.state == reserved) — > (ti.Ticket.book), 

eis : (ti .result == failure) => 

(t^.Room.unreserve V t^. Room. unbook), 

Di^5 May 2000, Rti = null. 

t2 = (A^2,P2,02,£?t2, £)2,/2t2), where 
N2 is hotel booking, P2 is required, 
O2 is Hotel Room, defined as: 



States 
Operations 
reserve 
unreserve 
book 
unbook 



{request, reserved, unavailable,booked } 



(request, reserved) 
(reserved, request) 
(reserved, booked) 
(booked, request) 

Et2 = {e2i,e22ie23},where 

€21 : {t2- Room. state —— reserved) => (->-* ti) 

C22 : {t I .Ticket. state == reserved) — y (t2. Room, book) 

€23 : {t2. result == failure) => 

(ti .Ticket, unreserve V ti ,Ticket.unbook), 

D2=10 May 2000. Rt2 = null. 

t3 = (iVa, i^, O3, Et3, X)3, Ht3), where 
N3 is car booking, P3 is optional, 
O3 is Car, defined as: 
States 
Operations 
book 
unbook 



{request, imavailable, booked } 



(request,booked) 
(booked, request) 

Et3 = <f>. D3=10 May 2000, Rtz = null. 



4.2 Composition Procedure 

We assume that the workflow integrator is used to define 
the business trip workflow specification, namely, IV. An 



instance of the workflow is executed as follows: 

Parsing Workflow Specifications 

The process agent receives the definition IV fi-om the 
user, then parses it. The workflow W consists of three 
tasks: ti,t2 are required tasks, is an optional task. The 
main responsibility of the process agent is to assign the 
given tasks to the available service agents on the Web. 

Searching For Service Agents 

The process agent queries the discovery agent for a suit- 
able service agent which can execute the task ti . The con- 
tent of the query message that it sends to the discovery agent 
is shown in Figure 4. 



Message Type 
Agent tdentity 
Group identity 
Task Object 
Search 
Hop 



query 

7 
? 

ti .Ticket 

all 

3 



Figure 4. Query Message 

Upon receiving this message, the discovery agent 
searches its yellowpage and catalogue repositories (since 
the query indicates searching through all repositories of a 
discovery agent), then returns the result to the process agent 
as shown in Figure 5. The hop count is set to 3, which 
means that the request will be propagated to at least three 
discovery agents. The above message indicates that the 

Message Type reply 

Yellowpage (ip=203.5.1.2,port=1334, agent name=Flight_agent) 

Catalogue (ip=230.0.0.1.port=3333, group name=FlightTicket) 



Figure 5. Result Message 

process agent discovers one service agent and one group 
service agents which can execute the task. 

Assigning Tasks 

Assigning a task to a service agent has two phases. 

1 . Negotiation Phase 

In this phase, the process agent sends a pro- 
posal message as shown in Figure 6 to the service 
agents(Flight^gent, Traveller) and the service agent 
group(FlightTicket). The service agents who are able 
to execute the task will send the corresponding re- 
sponse messages as shown in Figure 7. 

2. Task Assignation Phase 

In this phase, the process agent presents the responses 
to the user and let the user select the most appropriate 



Message Type 
Sender 
Task Object 
Price 



proposal 

203.5. 1 5.2 1 : 1 234:Process.agent 
ti .Ticket 

9 



Figure 6. Pr p sal Message 



Message Type 
Sender 
Task 
Price 



response 

203.5. K2:1334:Flight_agent 

tl .Ticket 

ASIOOO 



Figure 7. Response Message 



This instantiated task's ECA rules will be downloaded by 
the monitor agents. After all the tasks have been assigned to 
the service agents, all the monitor agents have been created 
and migrated to the tasks' execution sites and have down- 
loaded the instantiated task ECA rules, the workflow agent- 
community is ready to execute the cross-enterprise work- 
flow instance. Note that the composed agent-community 
is not a static entity. It might dynamically change- during- 
the execution of the workflow. For example, if the assigned 
service agent fails to execute the task, the process agent can 
locate an alternative service agent and continue executing 
the workflow. 



service agent. It then assigns the task to the service 
agent (which is selected to execute the task) by 
sending the assignment message shown in Figure 8. 
In this message, the process agent assigns the task ti 
to the service agent Flight^agent. Here, task ti is a 
tuple as we defined in section 4.1 which has all the 
detailed information about the task. After the service 

Message Type assign 

Sender 203.5. 15.21:1 234: Process-agent 

Task tl 

Receiver 203.5.1. 2: 1334:Flight_agent 

Figure 8. Assign Message 

agent receives the assign message, it will send a 
confirmation message to the process agent. 

Creating Monitor Agents 

For every task that is assigned to the service agent, the 
process agent creates a monitor agent for it. The monitor 

agent migrates to the site of the service agent (which is 
selected to execute the task). After the monitor agent 
arrives at the service agent site, it will send a confirmation 
message to the process agent to signal that it is ready to 
monitor the task. 

Instantiating the ECA rules 

The task ECA rules do not have any execution con-, 
text information and can not be executed when users first 
define these rules. Only after monitor agents have mi- 
grated to the tasks' execution site, the rules can be in- 
stantiated by the process agent. For example, assuming 
the tasks ii,*2,*3 have been assigned to service agents 
Flight .agent. Hotel-agent, Car-agent, and mon- 
itor agents MAi , MA2, MA^ have migrated to tasks' exe- 
cution sites respectively, then the ECA rule en: 

{t^'Room.atate =— reserved) — ► {t\.Tickei.book') 

can be instantiated to 

{i2{M A^) Room. state reserved) — ► {i\{M Ax)Ticket.book)\ 



4.3 Distributed Enactment of a Cross-Enterprise 
Workflow 

Normally, workflow engine acts as a central task coordi- 
nator. Based on the specification, it creates process instance 
and task list, controls over the execution flow of the tasks 
and coordinates task execution as well. Such a central con- 
trol model obviously has some drawbacks when task exe- 
cution is carried out in a widely distributed network envi- 
ronment, especially when exceptions arise during the coor- 
dination and the task execution. These drawbacks include: 
central server is a single point of failure; when exception 
occurs, central server needs to suspend the whole workflow 
instance to handle it. 

We propose a distributed coordination approach which 
adopts the mobile agent technology. We separate the task 
control flow and the task coordination: the process agent 
implements the task execution flow control; the monitor 
agents act as task coordinators to be distributed in all the 
task execution sites. 




Figure 9. Distributed Coordination 

In the following, we use a simple example to ex- 
plain how distributed coordination works. Here, we 
assume workflow agent-community has been formed 
for the workflow specification W, four tasks have been 
assigned to three service agents (Flight-agent, Ho- 
tel-agent, Car_agent) respectively, three monitor 
agents {MA\^MA2yMAz) have been created and mi- 
grated to each of the task execution sites (Figure 9), all the 
tasks' ECA rules have been instantiated and downloaded 



by the monitor agents. 

Starting the Workflow 

At the beginning, the process agent will execute the first 
workflow ECA rule: 

e^i : => Ati(M^i) A AtaCM^a) 

The action Ati{MAi) and AtaC^^-^a) results in sending 
messages to monitor agent MAi and MA2 which will 
inform service agent Flight .agent and Hotel ^gent 
to start executing their tasks. 

Executing the Task U and t2 

Flight-agent and Hotel^gent begin to exe- 
cute their tasks after they received the enable signal 

(Atj) message from the process agent. We assume that 
Flight -agent reserves the ticket first. The Object 
Ticket's state will be changed to reserved, it will then 
trigger the action taCM^a) which will send event mes- 
sage (Figure 10) to the monitor agent MA2. This event 
satisfies the condition of is. €32 which is a * — type of 
rule and does not trigger an object's changing states event 
but indicates that the object's state can be changed from 
reserved to booked. So, if the service ageiit Ho- 
tel-agent has already reserved the room, it can issue the 
booking operation now. 

Message Type event 

Sender 203,5. 1.2:2234:M>li 

Event : ti (Flight-agent).Ticket. state = reserved 

Receiver 203.5.25.21 r2234:M>l 2 

Figure 10. Event Message 

If both Flight _agent and Hotel_agent make 
the booking, the results from both task executions are 
successful. The monitor agents MAijMA2 located at 
Flight-agent and Hotel-agent will relay messages 
to process agent about the their tasks' state and trigger the 
dependent task which happens to be task <3. On the other 
hand, the service agent may not be able to make the re- 
quired bookings, for example, no ticket might be available 
from service agent Flight-agent. In this situation, if 
the deadline constraint is not violated, the process agent 
will seek alternative service agent to perform task ti and 
re-instantiate ti's ECA rules. The monitor agent MAi will 
update its ECA rules and migrate to the new task execution 
site. If task ti is overdue, the task ti 's result will be a fail- 
ure. MAi will be informed of such a failure by MA2 and 
it will execute the task's ECA rule 622* 

(ti (Flight. agent). result == failure) => 

(t2{HotelMgent) . Room. unreserves/ 

t2{ Hotel -agent). Room. unbook) 



This is a '=>' type of ECA rule which means it will 
trigger the indicated events and force the service agent 
Hotel-agent to issue operation either unreserve or 
unbook. 

Executing the Task ^3 

Task *3 is an optional task. If the service agent 
Car-agent successfully executes the task, the whole 
workflow wil! finish. If Car-agent can not book the 
car, process agent can either find another service agent or 
choose to skip that task. 

Finishing the Workflow 

After task *3 gets the result, process agent will finish the 
workflow and pass the result of execution to the user. 

5 Related Work and Conclusions 

Techniques related to integrating business processes ex- 
ist in several fields including EDI, component-based E- 
conunerce systems, databases, agents, and groupware sys- 
tems. 

EDI aims at offering an automatic and standard way to 
transfer data between business partners. EDI investigated 
static solutions that are appropriate if the business systems 
to be integrated belong to organizations that have long- 
term and static trading relationships. Component-based E- 
commerce systems [Dog98] typically rely on distributed ob- 
ject middleware technologies such as CORBA and DCOM. 
They focus on the integration of a small number of tightly 
coupled applications. However, they present several limita- 
tions that make them ineffective when the service space is 
large and highly dynamic (e.g., the cost to set up a new busi- 
ness relationship is very high, it is not presently possible to 
dynamically integrate new business services, etc.) 

Other advanced approaches to dynamic composition of 
cross-organization workflows include the CMI[GSCB99] 
project at MCC and eFlow[CIJ"*"00] at HP labs. In CMI, 
they proposed a Service Oriented Process model and a 
set of service management primitives such as activity 
place holder, dynamic role assignment, re- 
peated option creator, awareness events, 
process synchrony etc. The goal is to be able to pro- 
vide a firamework for flexible, plug and play approach to 
cross-organization workflow composition. However, CMI 
has not addressed the issue of brokering and selection of 
services that goes beyond what is stated in the service inter- 
faces. 

eFlow is a platform that supports the specification, enact- 
ment, and management of composite e-services. A compos- 
ite service is described as a process schema that composes 
other basic or composite services. It aims to provide a flex- 
ible, configurable and open approach to cross-organization 



workflow composition. The flexibility is achieved mainly 
by allowing dynamic service process modiflcation and bind- 
ing of services through dynamic service discovery. Both 
CMl and eFlow emphasis on a process model that allows 
incomplete or abstract specification of the workflow at de- 
sign time to allow for more dynamic adaptation at runtime. 

The use of agents in executing a single organization 
WFMS have been discussed in several publications, e.g. in 
[CS96, JFJ+96, PM99]. In [CS96], each workflow is rep- 
resented by multiple personal agents, actor agents and au- 
thorization agents. These agents act as personal assistants 
performing actions on behalf of the workflow participants 
and facilitating interaction with other participants or orga- 
nization specific WFMS. In [JFJ+96], the multi-agent ar- 
chitecture consists of a number of autonomous agencies. 
A single agency consists of a set of subsidiary agencies 
which is controlled by one responsible agent. Each agent is 
able to perform one or more services. These atomic agents 
can be combined to form complex services by adding or- 
dering constraints and conditional control. However, nei- 
ther [CS96] nor [JFJ***96] adopts agent technology to com- 
pose workflow execution engine dynamically. The logic for 
workflow processing is hard-coded and thus it is hard to 
reuse this workflow execution engine for other business pro- 
cesses. In [PM99], a multi-plan state machine agent model 
is presented. Agents are assembled dynamically from the 
descriptions in a blueprint language and can be modified 
while running. But users have to describe in detail how 
agents can be assembled together and what changes are al- 
lowed in priori. 

In our approach, the agent-community for a specific 
workflow execution is optimally and automatically com- 
posed based on the context of workflow execution and 
can self-adapt and react to changes during the execution. 
Our approach aims to achieve the similar result as CMI 
and eFlow, with the added benefit of scalability, distribu- 
tion and interoperability as inherent in multi-agents system. 
We show how the workflow agent-community gets con- 
structed through an example. We illustrate how the agent- 
community executes the workflow specification and modi- 
fies themselves during the execution of the workflows. We 
also show a novel distributed monitoring of cross-enterprise 
workflow using monitor agents. This enables user to be 
aware of the status of the workflow instance without hav- 
ing to pay the high subscription cost to any service agent. 

We are currently implementing prototype for composing 
workflows based on XML and EJB (Enterprise Java Beans) 
technologies. 
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